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PROTECTION OF A PROGRAM WATTING TO BE EXECUTED IN A MEMORY USED BY 

A MICROPROCESSOR 

Priority Claim 

[1] This application claims priority from French patent application No. 03/04149 filed on April 3, 
5 2003, which is incorporated herein by reference. 

BACKGROUND OF THE INVENTION 

Field of the iNVErmoN 

[2] The present invention relates to the field of micro-processors and more specifically to 
multitask circuits capable of executing, at least fiiom the user's viewpoint, several programs 
1 0 simultaneously. In practice, a single instruction of a program is processed at each time by a 
central processing unit (CPU) but several programs or program sections are stored in a RAM 
by the CPU which transfers lines of the program to be executed to a cache memory assigned 
thereto. 

Discussion of the Related Art 

1 5 [3] FIG, 1 is a schematic block diagram of an example of a simplified architecture of the type to 
which the present invention applies. A CPU 1 equipped with a cache memory 2 (CACHE) is 
connected to one or several buses 3 of communication (data, addresses, control signals) with 
peripheral elements. Among the peripheral elements, a RAM 4 intended to contain the data 
(operands) of the programs being processed as well as the code lines of these programs (at 

2 0 least by blocks) is connected to bus 3. In practice, the programs contained in memory 4 
generally originate finom a mass storage 5 (MMEN), for example, a hard disk. This mass 
storage contains the programs likely to be executed by the CPU as well as the data saved 
when these programs are not being executed. Of course, several mass storages (CDROM, 
floppy disk, etc.) may be connected to bus 3. 

2 5 [4] To execute several different applications or programs temporarily stored in memory 4, CPU 
1 must have a table of correspondence between so-called virtual addresses of the program, 
which are independent ftiom its storage location, and so-called physical addresses 
corresponding to the physical addresses in the memory, for example memory 4, where the 
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different program lines are stored. This correspondence table is generally stored in buffers and 
is generally designated as a TLB (Translation Look Aside Buffer). 

[5] FIG. 2 schematically and functionally illustrates a correspondence table 10 and the 
exchanges between the cache memory or register containing this table and the different 
5 elements using it. 

[6] On the side of CPU 1, each time an instruction of a program stored in RAM 4 must be 
executed, this instruction is called by using virtual address VirtAD of this instruction 
conesponding to the address contained in the program. This virtual address is converted by 
table 10 into a physical address PhysAD where this instruction is located in RAM 4. RAM 4 
1 0 then provides the corresponding instruction over the bus (3, FIG. 1 ) to the CPU. 

[7] If table 10 does not contain the correspondence t)e1ween the two addresses, the CPU or, 
more specifically, a calculation program (block 11, CALC) of its exploitation system calculates a 
new correspondence line between the virtual address and the physical address, and writes it 
into correspondence table 10, 

1 5 [8] Each time an application contained in RAM 4 must be executed by the CPU, the 

exploitation system takes over and uses its internal structures to calculate the con"espondence 
table for the involved program. 

[9] FIG. 3 illustrates the fact that two different applications APPLt and APPL2 stored in RAM 4 
at different physical addresses (PhysAD(k) to PhysAD(m) for the first program and PhysAD(n) 
2 0 to PhysAD(p) for the second program) share identical virtual addresses (VirtAD(1 ), VirtAD(2), 
VirtAD(i), etc). Each time a program comes to the foreground, tiiat is, is executed by CPU 1 
(possibly after transfer into cache memory 2), its correspondence table 10 is used to convert its 
virhjal addresses into physical addresses in memory 4. 

[10] For security reasons in the program execution, it is important for two identical virtijal 
2 5 addresses of two different applications not to point to tiie same physical address in memory 4. 
Indeed, this enables protecting tiie program code, as well as the application data, from one 
anotiier. For example, if critical data (secret quantity, secret result, ete.) of a first application are 
located at a physical address t)etween addresses k and m in memory 4 while they are 
assigned a virtual address i, absolutely no other application must be able to access the 
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cxDmesponding physical address by reusing virtual address i. In an architecture of the type in 
FIG. 2, the correspondence table must be reset each time it is switched from one application to 
another. This imposes recalculating the correspondence table each time an application 
switches to a foreground execution, that is, one of its instructions must be executed by the 
5 CPU. 

[1 1] An obvious disadvantage is that this takes time. 

[12] FIG. 4 schematically illustrates the architecture of a conventional solution avoiding 
recalculation of tiie correspondence table each time an application comes to the foreground. 
This solution uses an additional field of correspondence table which contains, for each line, 
10 an identifier ASID of the application in addition to the virtual and physical addresses. This 
enables, in principle, avoiding association of an application witti a physical address 
corresponding to another application. 

[13] To implement this solution, tiie circuit uses a register 20 (ASIDREG) containing tfie 
identifier of the current application. This register is a state register of CPU 1. 

1 5 [14] This solution has tiie advantage, as compared to ttiat of FIG. 2, of not requiring resetting 
or emptying tiie correspondence table each time tiie foreground task is changed. 

[15] A disadvantage however remains that it is tiie exploitation system that assigns identifiers 
ASID to the different applications when an application is loaded into tiie RAM tor execution. 
The area of RAM 4 assigned to a suspended (background) application accordingly becomes 

2 0 more vulnerable to possible attacks. Indeed, flom the moment that the correspondence table 
is not integrally recalculated when the application comes to tiie foreground, it is possible to 
replace tiie RAM witii an emulator, or to modify the signals on bus 3, to modify an operation 
code of a background application and insert a pirate instruction (of virus or Tnojan horse" type) 
tiierein. Then, when the modified application comes back to the foreground, it can tiien have 

2 5 access to tiie physical addresses which have remained present in tiie correspondence table 
upon former execution of the modified application (/.e., before it has been modified). 

[16] This vulnerability of a background application is increased by the fact tiiat it is not 
necessary to be synchronous witti tiie CPU to modify tiie lines of this memory. 
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[17] A similar problem is posed for mass storage 5\A/hen the program is not integrally loaded 
into RAM 4 and its execution requires data line calls in mass storage 5. 

Summary of the Invemtion 

[18] An embodiment of the present invention aims at providing a method for allo\A/ing access 
5 to a correspondence table which overcomes the disadvantages of known solutions. In 

particular, an embodiment of the present invention aims at avoiding systematic recalculation of 
a correspondence table at each foreground loading of an application to be executed, without 
making it vulnerable when it is in the background in a RAM. 

[19] An embodiment of the present invention also aims at providing a solution which is 
1 0 compatible with conventional uses of correspondence tables. 

[20] An embodiment of the present invention provides a method for allowing access to a table 
of address correspondence between a multitask CPU and at least one memory containing 
several programs, consisting of calculating, on each task change of the CPU, a signature of at 
least part of the program instruction lines and of checking the conformity of this signature to a 
1 5 signature recorded upon previous execution of the involved program. 

[21] According to an embodiment of the present invention, said signature is calculated by the 
implementation of a Hash function. 

[22] According to an emtxxliment of the present invention, said memory is a RAM in which are 
loaded program lines ftom a mass storage. 

2 0 [23] An embodiment of the present invention also provides a processor of multitask execution 
of several programs, exploiting a table of correspondence between virtual addresses of the 
lines of the different programs and physical addresses of these lines in at least one memory, 
each correspondence being associated with an identifier of the involved program, comprising 
means for calculating a current signature based on at least part of the program lines in said 

2 5 memory, and means for comparing this signature with the identifier of the program stored in the 
correspondence table. 

[24] According to an emtxxliment of the present invention, tiie identity of the signature and of 
the program identifier allows the CPU to execute the instruction of tiie involved program. 
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P5] The foregoing features and advantages will fc>e discussed in detail in the following non- 
limiting description of specific embodinnents of the present invention in connection with the 
accompanying drawings. 

Brief DEScrapnoN of the Drawings 

5 [1] FIGS. 1 to 4, previously described, are intended to show the state of the art and the 
problem to solve; and 

P] FIG. 5 very schematically shows in the form of blocte an embodiment of a microprocessor 
architecture implementing the correspondence table access authorization method according to 
an embodiment of the present invention. 

10 Detailed Description 

[3] Same elements have been designated with same reference numerals in the different 
drawings. For darity, only those steps of the method and those elements of the processor that 
are necessary to the understanding of embodiments of the present invention have been shown 
in the drawings and will be descritjed hereafter. In particular, the calculation of actual 
1 5 correspondence tables has not been detailed, as such calculations can be implemented witii 
conventionally-used calculation tools. 

[4] A feature of an embodiment of the present invention is to calculate, at each context change 
(coming of a new application to tiie foreground), the identifier of tiie application by means of an 
aigoritiim executing a Hash function or tiie like calculating a signature of at least part of the 
2 0 code of the application stored in the RAM and/or in the mass storage. 

[5] Another feature of an embodiment of tiie present invention is to check tiie conformity of tiiis 
current calculated signatijre witii respect to a previously-calculated reference signatijre stored 
in tiie correspondence table. The reference signature calculation is performed on each 
calculation of a new correspondence between a virtual address and a physical address. This 
2 5 signature however always remains the same for a same application. 

[6] FIG. 5 schematically illustrates, in the form of blocks, an embodiment of the present 
invention. The representation of FIG. 5 mainly shows tiie functional links between tiie different 
elements. 
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[7] An embcxJiment of the present invention exploits an architecture of the type previously 
described in relation with FiG. 4, that is, exploiting an identifier ASID of the application or 
program associated with each correspondence line of table 10 between a virtual address 
VirtAD and a physical address PhysAD. As previously deiscribed, correspondence table 10 is 
5 used to convert virtual addresses of an application required by a CPU 1 provided with an 
application identifier register 20 (ASIDREG), into a physical address PhysAD of a RAM 4 in 
which is stored the concerned application. The CPU comprises hardware or software means 
(block 11, CALC) for having the physical addresses calculated by its exploitation system either 
at the loading of an application, or when a virtual address is called for tiie first time. 

1 0 [8] According to an emtxxliment of tiie present invention, each time an application (for 
example, a program or a subhprogram) contained in memory 4 (or in a mass storage not 
shown) t comes to the foreground, that is, at least one of its instructions is executed by CPU 1, 
a signature (block 30, HASH) of at least part of tiie lines of the program stored in memory 4 is 
calculated. This signature provides a current application identifier (CURASID) stored in register 

1 5 20. The content of register 20 is then compared (block 32, COMP) witfi the identifier ASID 
stored on the line of table 10 corresponding to the involved application which is desired to be 
used. The result of tiiis comparison enables verifying tiiat tiie operation code of the application 
has not been modified in the RAM while this application was in tiie background. Comparison 
block 32, be it hardware or software, provides an autiiorization or autiientication signal AUT to 

2 0 CPU 1 to take the appropriate measures. In practice, tiie CPU will only execute, or will only 
tiBnsfer into its cache memory for execution, tiie instiifctions of the program stored in RAM 4 if 
comparator 32 has auttienticated that the operation code has not been modified since its 
loading into memory 4. 

P] Preferably, tiie signatijre calculation is performed on a fixed significant portion of tiie code 

2 5 of the program stored in ttie RAM. "Fixed portion" means fliat lines containing data processed 

by the program, and tiie content of which is thus likely to change and to modify tiieir signature 
even when no piracy has occurred, should be avoided. "Significanf means that tiie larger the 
numtDer of code lines taken into account in the signature calculation, the more tiie 
autiientication will be robust in terms of efficiency. As an example, the signature can be 

3 0 calculated taking one line out of ten, one line out of twenty, or one line out of thirty of the 

operation code. 
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[1 0] An advantage of an embodiment of the present invention is that a modification of the 
operation code of a background program stored in a RAIVI becomes difficult since its operation 
code must be modified while respecting the signature, the calculation algorithm of which is in 
principle unknown. Preferably, to guarantee the system security and for rapidity reasons, the 
5 Hash function is executed in hardware fashion in an integrated circuit. 

[11] The application being executed necessarily is in the cache memory of the microprocessor 
which forms an area considered as untouchable for a pirate. Only when the application is 
pending in the RAM does there exist a risk of piracy. 

[12] It should be noted that if the totality of a program is not transferred from the mass storage 
1 0 (5, FIG. 1 ) to the RAM at the application loading, the signature calculation can exploit program 
lines still present in the mass storage. 

[13] An advantage of an embodiment of the present invention is that, without requiring 
recalculation of correspondence table 10 on each coming to the foreground of a new 
application, it prevents an operation code fifom being pirated when it is in the background in a 
1 5 multitask processing. Of course, the content of tiie lines of table 10 can be overwritten as it is 
filled, as conventionally used to be the case in the solution discussed in relation to FIG. 4. 

[14] Any conventional algoritiim executing a function of Hash type may be used. Among 
known algoritiims, one can mention, for example, the algorithm known as SHA-t which 
operates on 512-bit blocks and provides a 160-bit signatijre as an output. For tiie application of 

2 0 such an algorittim, the code or code portion of which a signatijre is desired to be obtained is cut 

into blocks of 512 bits for which are calculated, each time, five concatenated 32-bit words 
connesponding to the block signature. In this case, a single word out of the five 32-bit words of 
tiie signatijre may be used and tiie first words of several signatures calculated on different 
blocks may be added to obtain tiie current code CURASID of the application. 

25 [15] The architecture illustrated in and described with reference to FIG. 4 may be part of an 
electronic system, such as a computer system. 

[1 6] Of course, embodiments of tiie present invention are likely to have various alterations, 
modifications, and improvements which will readily occur to tiiose skilled in the art. In particular, 
tiie selection of the signatijre calculation algorittim preferentially depends on the size of the 

3 0 application identifiers used in the correspondence table and on tiie security level desired for the 
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system. Further, the selection of the operation code lines to be taken into account in the 
signature calculation is \A^in the abilities of those skilled in the art based on tiie functional 
indications given hereabove. Finally, afthough a hardware implementation of tiie signature 
calculation is preferred, embodiments of the present invention do not exclude a software 
5 implementation, 

[17] Such alterations, modifications, and improvements are intended to be part of tills 
disclosure, and are intended to be within the spirit and the scope of embodiments of the 
present invention. Accordingly, tiie foregoing description is by way of example only and is not 
intended to be limiting. 
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